Crc counter normalization

ABSTRACT

The ability to accurately and efficiently calculate and report communication errors is becoming more important than ever in today&#39;s communications environment. More specifically calculating and reporting CRC anomalies in a consistent manner across a plurality of communications connections in a network is crucial to accurate error reporting. Through a normalization technique applied to a CRC computation period (e.g., the PERp value), accurate error identification and reporting for each individual connection can be achieved.

RELATED APPLICATION DATA

This application claims the benefit of and priority under 35 U.S.C. §119(e) to U.S. Patent Application No. 60/613,594, filed Sep. 25, 2004,entitled “CRC Counter Normalization Method and System,” which isincorporated herein by reference in its entirety.

BACKGROUND Field of the Invention

This invention generally relates to communication systems. Moreparticularly, an exemplary embodiment of this invention relates toanomaly detection in communications systems.

Description of Related Art

Cyclic Redundancy Checksum (CRC) error detection is a common method ofdetecting errors in a data stream transmitted over a communicationschannel. ITU standard G.992.3, which is incorporated herein by referencein its entirety, describes CRC operations for ADSL systems in section7.7.1.2. As discussed in G.992.3, the transmitter computes thetransmitter CRC bits based on the transmitted bit stream and sends theCRC bits to the receiver. The receiver also computes the CRC bits basedon the received bit stream and compares the locally computed CRC bits tothe received CRC bits that were sent from the transmitter. If thereceiver and transmitter CRC bits are identical, then the CRCcomputation indicates that there are no errors in the received bitstream. If however the received and transmitted CRC bits are notidentical, then the CRC computation indicates that there are errors inthe received bit stream.

DSL systems, and communications systems in general, use CRC errors,which are also known as anomalies, to diagnose and detect problematicservice conditions. These CRC anomalies are typically computed, countedand reported based on some fundamental assumptions on how often the CRCsare computed. For example, in an ADSL systems, such as those specifiedin G.992.3, Severely Errored Seconds (SESs) are defined as 18 or moreCRC anomalies in a 1-second interval. This corresponds to approximately30 percent of computed CRCs being in error if the CRC is computed every17 ms. The G.992.3 ADSL standard requires that the CRC is computed every15 to 20 msecs. In ADSL 2 and VDSL 2 systems, the period of the CRCcomputation is called the period of the overhead channel (PERp). TheG.992.3 standard requires that:

15 ms≤PERp≤20 ms.

SUMMARY

Digital subscriber line service providers use CRC anomaly reporting as away to diagnose and detect problematic service conditions. For example,an ADSL service provider may use SESs as a way to detect an ADSLconnection that is experiencing problems. For example, an ADSL serviceprovider may specify that if an ADSL subscriber is experiencing morethan 30 SESs in a 1-minute period, the ADSL connection needs to berepaired. For this reason, it is important that an SES is reported in aconsistent manner across all connections in the service providernetwork.

As discussed above, if an ADSL system is determining CRCs every 17 ms(the PERp as required by the standard), Severely Errored Seconds (SESs)are defined as 18 or more CRC anomalies in a 1-second interval, then anSES will occur whenever approximately 30 percent of the computed CRCsare in error in a 1-second interval. But if, for example, CRCs arecomputed every 2 ms, and a SES is still defined as 18 or more CRCanomalies in a 1-second interval, then 18 CRC anomalies will correspondto only 3.6 percent of a computed CRC being in error. In this case, theservice provider may receive a repair alarm and dispatch a networktechnician to fix a connection that is only experiencing a small numberof errors.

Most communications systems specify CRC operations in a manner thatrestricts the CRC computation to be within a specified and boundedrepetition period or rate in order to provide consistent detection anddiagnostic capabilities across all connections, such as DSL subscriberconnections, in a network.

New designs and innovations in communications systems are making it moredifficult to ensure that CRC computations are bounded in such a manner.For example, G.992.3 specifies Seamless Rate Adaptation (SRA) andDynamic Rate Repartition (DRR) that allow an ADSL system to makeseamless changes in data rates on-line. However, SRA and DRR modify thedata rate without changing the framing parameters. As a result, the PERpwill change in proportion to the data rate change.

For example, a data rate increase of 10 percent will cause the PERp todecrease by 10 percent. A problem is that since PERp is only allowed tovary between 15 and 20 ms, SRAs and DRRs are limited to small data ratechanges, usually within 10 to 15 percent.

It is often desirable to have large data rate changes. Large data ratechanges typically result in PERp values that are outside of the range of10-20 ms. In this case, as discussed above, ADSL service providers willencounter problems with the diagnostic procedures which are based on CRCanomalies to detect problematic connections.

New communications systems, such as VDSL, VDSL2, and other higher-speedwired and wireless communications systems are specifying data rates thatoccupy a very large range, starting, for example, as low as 500 kbps andgoing as high as 100 mbps or more. With ranges this large, it isdifficult to design a framing method for all possible data rates thatincludes a CRC procedure that restricts the CRC computation to be withina specified and bounded repetition period.

Part of this difficulty is attributable to the fact that the accuracy ofthe error detection of the CRC is correlated to the number of bits inthe CRC computation period (the accuracy of the CRC error detectiondecreases as the number of bits in the CRC computation periodincreases). For example, if the CRC computation is done every 20 ms, andthe data rate is 1 mbps, there will be 20,000 bits in every CRCcomputation period.

However, if the data rate is 100 mbps, and the CRC computation period is20 ms, then there will be 20 million bits in every CRC computationperiod. Clearly, the CRC error detection capability will be decreased inthe latter case. In general, under normal operating conditions, the oneoctet CRC used in DSL systems provides adequate error detection if theCRC computation period contains less than 100,000 bits.

Accordingly, an exemplary aspect of this invention relates tocalculating and reporting communication errors. More particularly, anexemplary aspect of this invention relates to calculating and reportingCRC anomalies in a consistent manner for all communications connectionsin a network independent of data rate or the CRC computation period(e.g., the PERp value) of each individual connection.

Additional aspects of the invention relate to handling CRC anomalies(errors) in such a manner that they are reported in a consistent wayregardless of the data rate or the CRC computation. An exemplary aspectdefines a procedure for normalizing CRC anomaly counters based on anactual CRC computation period.

According to an additional exemplary aspect of this invention, the CRCanomaly counter normalization procedure normalizes the CRC anomalycounter based on the current, or actual, PERp value.

According to an additional exemplary aspect of this invention, CRCanomaly counter normalization procedures are applied to a plurality ofcommunications devices in a network based at least on a data rate.

According to an additional exemplary aspect of this invention, differentCRC anomaly counter normalization procedures are applied to each of aplurality of communications devices in a network based at least on adata rate.

These and other features and advantages of this invention are describedin, or are apparent from, the following description of the embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the invention will be described in detail, withreference to the following figures, wherein:

FIG. 1 is a functional block diagram illustrating an exemplarycommunication system according to this invention;

FIG. 2 is a flowchart outlining an exemplary method for normalizing aCRC counter according to this invention.

FIG. 3 is a flowchart outlining in greater detail an exemplary method ofCRC normalization according to this invention;

FIG. 4 is another exemplary embodiment for normalizing CRC normalizationaccording to this invention; and

FIG. 5 is a functional block diagram illustrating a second exemplarycommunication system according to this invention.

DETAILED DESCRIPTION

The exemplary embodiments of this invention will be described inrelation to detecting errors in a wired and/or wireless communicationsenvironment. However, it should be appreciated, that in general, thesystems and methods of this invention will work equally well for anytype of communication system in any environment.

The exemplary systems and methods of this invention will be described inrelation to DSL modems and associated communication hardware, softwareand communication channels. However, to avoid unnecessarily obscuringthe present invention, the following description omits well-knownstructures and devices that may be shown in block diagram form orotherwise summarized.

For purposes of explanation, numerous details are set forth in order toprovide a thorough understanding of the present invention. It should beappreciated however that the present invention may be practiced in avariety of ways beyond the specific details set forth herein.

Furthermore, while the exemplary embodiments illustrated herein show thevarious components of the system colocated, it is to be appreciated thatthe various components of the system can be located at distant portionsof a distributed network, such as a telecommunications network and/orthe Internet, or within a dedicated secure, unsecured and/or encryptedsystem. Thus, it should be appreciated that the components of the systemcan be combined into one or more devices, such as a modem, or colocatedon a particular node of a distributed network, such as atelecommunications network. As will be appreciated from the followingdescription, and for reasons of computational efficiency, the componentsof the system can be arranged at any location within a distributednetwork without affecting the operation of the system. For example, thevarious components can be located in a Central Office (CO or ATU-C)modem, a Customer Premises Modem (CPE or ATU-R), a DSL managementdevice, or some combination thereof. Similarly, on or more functionalportions of the system could be distributed between a modem and anassociated computing device.

Furthermore, it should be appreciated that the various links, includingcommunications channel 5, connecting the elements can be wired orwireless links, or any combination thereof, or any other known or laterdeveloped element(s) that is capable of supplying and/or communicatingdata to and from the connected elements. The term module as used hereincan refer to any known or later developed hardware, software, firmware,or combination thereof that is capable of performing the functionalityassociated with that element. Furthermore, in order to simplifynotation, throughout this specification the term PERp will be used todenote the CRC computation period. The terms determine, calculate andcompute, and variations thereof, as used herein are used interchangeablyand include any type of methodology, process, mathematical operation ortechnique.

An exemplary embodiment of the present invention relates to CRCnormalization in asymmetric DSL (ADSL) service. However, and in general,it is to be appreciated that this methodology can be applied to any oneor more of a communications line or digital communications line.

FIG. 1 illustrates an exemplary embodiment of the communication system10 according to this invention. It should be appreciated that numerousfunctional components of the transceivers have been omitted for clarity.However, it should be understood that either transceiver can alsoinclude the standard components found in typical communicationsdevice(s) in which the technology of the subject convention isimplemented into.

The communications system 10 includes a transceiver 100 and atransceiver 200. The transceiver 100, acting as a transmittingtransceiver, includes a CRC bits computation module and a CRC bitstransmission module. The two transceivers are interconnected bycommunications channel 5, which, as discussed above, can be one or moreof a wire line and wireless communication channel. The transceiver 200comprises a CRC bits computation module 210, a CRC bits reception module220, a CRC bits comparison module 230, a CRC error counter and reportingmodule 240, a PERp determination module 250, a normalization module 260,a CRC grouping module 270 and a communication parameter module 280.

In accordance with an exemplary embodiment, a CRC anomaly is counted as:

PERp/K normalized anomalies,

where K is any positive integer. For example, if K=20 and the PERp=25,then each CRC anomaly is counted as 1.25 normalized CRC anomalies. Ingeneral, K will correspond to a value equal to an expected period of CRCcomputations based on which the system diagnostic information isreported. For example, in ADSL and VDSL systems, K can be equal to 15 mssince this corresponds to approximately 66 CRC computations per second.As discussed above, a Severely Errored Second is reported when there aremore than 18 CRC anomalies in a second, which corresponds toapproximately 30 percent of the CRC computations being in error.

Since CRC anomalies are typically reported as integer numbers, theaccumulated CRC anomaly count can be rounded up to the next higherinteger. For example, if the PERp=28, then each CRC anomaly is countedas 28/20=1.4 normalized CRC anomalies. If there 23 CRC anomaliesdetected over a period of time, the accumulated CRC anomaly countercould contain ceiling (23*1.4)=ceiling (32.2)=33 normalized CRCanomalies, where ceiling indicates a rounding in the upward direction.

In operation, the transceiver 100, which in this exemplary embodiment isoperating as a transmitting transceiver or transmitting modem, computesCRC bits based on a transmitted bit stream. More specifically, a bitstream is transmitted from the transceiver 100 with the CRC bitscomputation module 110 determining CRC bits based on the transmitted bitstream. The number of CRC bits is usually 8 (1 octed), however thenumber of bits can be varied based on, for example, the specificimplementation of the invention. In conjunction with the CRC bitstransmission module 120, the transceiver 100 sends the transmitted bitstream along with the corresponding computed CRC bits to transceiver 200via communications channel 5.

The transceiver 200, which can also be referred to as the receivingtransceiver or receiving modem, receives the bit stream transmitted bythe transceiver 100 and, with the cooperation of the CRC bits receptionmodule 220, the CRC bits that were determined by the CRC bitscomputation module 110. Upon receipt of the bit stream, the CRC bitscomputation module 210 also computes CRC bits (i.e., the local CRC bits)based on the received bit stream. Knowing the CRC bits determined by theCRC bit computation module 110, and the CRC bits computed by the CRC bitcomputation module 210, the CRC bits comparison module 230 performs acomparison between the two and, in conjunction with the CRC errorcounter and reporting module 240, computes and identifies a CRC anomalywhen the local CRC bits are not identical to the received CRC bitsdetermined in transceiver 100.

The PERp determination module 250 then determines a value for the periodof a CRC computation (PERp). This period can be, for example, in secondsor in general any time period as appropriate for the particularcommunication environment. In conjunction with the normalization module260, the CRC error counter and reporting module 240 is normalized basedon the PERp value, where the normalizing of the CRC error counter 240comprises incrementing the CRC error counter by a value of M wherein thevalue of M is:

PERp/K,

where K is a positive integer.

The communication parameter module 280 monitors communicationparameters, such as one or more of data rate, Forward Error Correction,interleaving, framing, or in general any communication parameter, andtriggers the determination of an updated value for the period of a CRCcomputation should one or more of these parameters change. This updatedor second value for the period is then used by the CRC anomaly counterfor subsequent CRC anomaly counts.

In a second exemplary embodiment, CRC computations are combined intogroups of ceiling(K/PERp) CRC computations and any number of CRCanomalies in a group is counted as only 1 normalized CRC anomaly, whereK is a positive integer. In general, K will correspond to a value equalto an expected period of CRC computations based on which the systemdiagnostic information is reported in conjunction with the CRC errorcounter and reporting module 240. The CRC computations are grouped inthis manner in order to avoid over counting the CRC anomalies in thatmultiple CRC anomalies that occur within a specific time period (e.g., Kms) may the need to be counted as a single normalized CRC anomaly.

EXAMPLES

K=15 ms and PERp=10 ms: CRC computations are combined in groups ofceiling(15/10)=2 CRC computations. The first 2 CRC computations are thefirst group, the second 2 CRC computations are the second group, and soon. One or more CRC anomalies in a group are counted as 1 normalized CRCanomaly.K=25 and PERp=4 ms: CRC computations are combined in groups ofceiling(15/4)=4 CRC computations. The first 4 CRC computations are thefirst group, the second 4 CRC computations are the second group, and soon. One or more CRC anomalies in a group are counted as 1 normalized CRCanomaly

If correct CRC computations are denoted as “o” and errored CRCcomputations (anomalies) as “x,” then for the following stream of CRCcomputations:

-   -   ooxxxooxoxoxxxxoooooxxooxoooooo        if PERp=10, then 9 normalized CRC anomalies are counted:

oo ox xx oo xo xo xx xx oo oo ox xo ox oo oo oo

If PERp=4, then 6 normalized CRC anomalies are counted:

-   -   ooox xxoo xoxo xxxx oooo oxxo oxoo oooo

The CRC computations could also be combined in groups based on somemetric other than ceiling(K/PERp). For example, floor(K/PERp) could beused or 2*ceiling(K/PERp). In general, groups of CRC computations can bebased on the metric:

N*ceiling(K/PERp)

where, N and K are positive integer values and where floor indicates arounding in the downward direction.

Alternatively, and in addition, the CRC anomalies in a group could becounted as more than 1 normalized CRC anomaly. For example, 1 CRCanomaly in a group could be counted as 1 normalized CRC anomaly. 2-3 CRCanomalies in a group could be counted as 2 normalized CRC anomalies. 4-6CRC anomalies in a group could be counted as 4 normalized CRC anomalies,and so on.

Alternatively, and in addition, a sliding window could be used whengrouping the CRC computations.

Alternatively, and in addition, the normalized CRC anomalies may bescaled again based on the time duration of the group of CRCcomputations. For example, if the PERp is equal to 14 ms, then the CRCcomputations are combined in groups of ceiling(14/15)=2 CRCcomputations. According to the method described above, 1 normalized CRCanomaly is counted for each group of 2 CRC computations containing atleast 1 CRC anomaly. But combining the CRC computations into groups of 2results in an effective CRC computation period of 2*14=28 ms whichexceeds the 20 ms requirement of the G.992.3 standard. In this case, aswas done above when PERp>20 ms, the CRC anomalies can be scaled again tomake the CRC anomaly counts more accurate. For example, the 1 normalizedCRC anomaly can be further scaled and counted as (28)/20=1.4 normalizedCRC anomalies.

More generally, if the time duration of the group of CRC computationsexceeds the required range (e.g. 20 ms for G.992.3 ADSL systems) then:

1 normalized group CRC anomaly=[(time duration of CRC group)/K]normalized CRC anomalies

where K is a positive integer. For example K could also take on thevalues of 15, 17.5, or 20, which correspond to lower, middle and uppervalues in the range of the PERp values in the G.992.3 standard.

Using the G.992.3 ADSL standard as an example the values of PERp forwhich the normalized CRC anomalies could be determined and furtherscaled (or normalized) to account for the fact that the time duration ofthe CRC group is longer than 20 ms:

10<PERp<15

When the PERp value is greater than 10 and less than 15, each group ofCRC computations will contain 2 CRC computations (as based onceiling(15/PERp)). For this range of PERp values, the time duration ofeach CRC group will be longer than 20 ms. For example, if PERp=12 ms,then the time duration of the CRC group will be 2*(12 ms)=24 ms. In thiscase, the normalized CRC computations can be further normalized orscaled by 2*PERp/K, where K is equal to an integer such as 15, 17 or 20.

6.67<PERp<7.5

When the PERp value is greater than 6.67 and less than 7.5, each groupof CRC computations will contain 3 CRC computations (as based onceiling(15/PERp)). For this range of PERp values, the time duration ofeach CRC group will be longer than 20 ms. For example, if PERp=7 ms thenthe time duration of the CRC group will be 3*(7 ms)=21 ms. In this casethe normalized CRC computations can be further normalized or scaled by3*PERp/K, where K is equal to an integer such as 15, 17 or 20.

As a result, in one exemplary embodiment of this invention, normalizedCRC anomalies in an ADSL or VDSL2 system are further normalized (orscaled) if the PERp value is between 10 and 15 ms or between 6.67 and7.5 ms.

In another exemplary embodiment the PERp changes are based on a changein an on-line data rate, for example due to an SRA or a DRR change. Inthis case, the CRC normalization procedure would be updated based on thenew PERp value, where the new PERp value is associated with the updateddata rate.

FIG. 2 outlines a high-level overview of an exemplary embodiment of CRCnormalization according to this invention. In particular, control beginsin S200 and continues to step S210. In step S210, a CRC computationperiod (PERp), or updated CRC computation period (PERp), is received ordetermined. Then, in step S220, the CRC error counter is normalizedbased on the CRC computation period (PERp) or the updated CRCcomputation period (PERp). Control then continues to step S230 where thecontrol sequence ends.

FIG. 3 outlines an exemplary embodiment of CRC normalization in greaterdetail. In particular, control begins in step S300 and continues to stepS310. In step S310 the transceiver, acting as a transmitter, determinesthe CRC bits for a transmitted bit stream. The transceiver then sendsthe determined CRC bits and bit stream to the receiver in step S320.

In step S330, another transceiver, acting in its receiving capacity,receives the determined CRC bits and bit stream. Next, in step S340, CRCbits are determined for the received bit stream (local CRC bits). Next,in step S350, the local CRC bits are compared to the CRC bits determinedand forwarded by the transmitter. Control then continues to step S360.

In step S360, the CRC computation period is determined. Next, in stepS370 the CRC anomaly counter is normalized based on the CRC computationperiod (PERp). Control then continues to step S380.

In step S380, a determination is made whether CRC errors or anomaliesare present. If CRC errors are present, control continues to step S390otherwise control jumps to step S395.

In step S390, the CRC error count is generated and an indicator ofseverely errored seconds reported, if appropriate. In addition to thereporting of severely errored seconds, it should be appreciated thatalternative action could also be taken upon the determination of CRCerrors. For example, Errored Seconds (ES) could be reported, where anerrored second is typically defined as a second in which there is one ormore CRC error events. Alternatively, CRC errors can be compiled overperiods of time other than seconds, such as minutes, hours or sub-secondintervals.

In step S395, a determination is made whether there has been a change incommunication parameters. If there has been a change in one or morecommunication parameters, control jumps back to step S300 and theprocess repeated where a second or updated CRC computation period isdetermined in step S360. If there has not been a change in one or morecommunications parameters, control continues to step S399 where thecontrol sequence ends.

FIG. 4 outlines another exemplary embodiment of CRC normalizationaccording to this invention. In particular, control begins in step S400and continues to step S410. In step S410 the transceiver, acting itscapacity as a transmitter, determines the CRC bits for a transmitted bitstream. The transceiver then sends the determined CRC bits and bitstream to the receiver in step S420.

In step S430, another transceiver, acting in its receiving capacity,receives the determined CRC bits and bit stream. Next, in step S440, CRCbits are determined for the received bit stream (local CRC bits). Next,in step S450, the local CRC bits are compared to the CRC bits determinedand forwarded by the transmitter. Control then continues to step S460.

In step S460, the CRC anomalies are grouped. Next, in group S470 a countis performed with control continuing in step S480. In step S480, adetermination is made whether severely errored seconds are present. Ifseverely errored seconds are present, control continues to step S490.

In step S490, an indicator of severely errored seconds is generated and,for example, forwarded to an appropriate destination or an actiontriggered.

In step S495, a determination is made whether there has been a change incommunication parameters. If there has been a change in one or morecommunication parameters, control jumps back to step S400 and theprocess repeated where an updated grouping is performed in step S460. Ifthere has not been a change in one or more communications parameters,control continues to step S500 where the control sequence ends.

It should be appreciated that while certain functionality describedherein is illustratively performed in one or more of the transceiver 100and transceiver 200 that some or all of the steps can be performed inany apparatus that may or may not be colocated with one or more of thetransceiver 100 and transceiver 200. For example, the functionalityperformed by the PERp determination module and normalization module canbe outsourced to another module with the normalization value forwardedback to and applied to the CRC error counter and reporting module 240.Moreover, the sequences of events described herein are for illustrativepurposes only and may also be rearranged as appropriate.

More particularly, FIG. 5 illustrates an exemplary embodiment of a CRCnormalization management system. As with the communication system 10,the CRC normalization management system includes one or moretransceivers 100 each connected, via a communications channel, to theone or more transceivers 300. Each of the transceivers 300 are incommunication with the CRC management module 500. The CRC managementmodule 500 includes a PERp determination module 510, a normalizationand/or grouping module 520 and a CRC error counter and reporting module530. The CRC management module 500 at least allows normalization and/orgrouping of one or more CRC error counts from a centralized location.For example, the CRC bits comparison modules 550 forward and indicatorof a CRC error(s) to the CRC management module 500. The transceiver 300can also determine and forward a value for the period of a CRCcomputation (PERp) with the cooperation of the PERp determination module540. The management module, if needed, and with the cooperation of thePERp determination module 510, can also determine a value for the periodof a CRC computation (PERp) for each of the one or more transceivers300.

Having received a report of one or more errors from the one or more CRCbits comparison modules 550, the normalization/grouping module updatesthe CRC error counter and reporting module 530 based on this value. Inthat each transceiver could be operating under different communicationparameters, the values used to update the CRC error counter 550 could betransceiver specific, applied to a portion of the transceivers or to alltransceivers. The CRC error counter and reporting module 530 could thenoutput, as discussed above, a normalized CRC error count. For example,an indicator of severely errored seconds could be generated and, forexample, forwarded to an appropriate destination or an action triggered.

The above-described system can be implemented on wired and/or wirelesstelecommunications devices, such a modem, a multicarrier modem, a DSLmodem, an ADSL modem, an XDSL modem, a VDSL modem, a linecard, testequipment, a multicarrier transceiver, a wired and/or wirelesswide/local area network system, a satellite communication system, amodem equipped with diagnostic capabilities, or the like, or on aseparate programmed general purpose computer having a communicationsdevice or in conjunction with any of the following communicationsprotocols: CDSL, ADSL2, ADSL2+, VDSL1, VDSL2, HDSL, DSL Lite, IDSL,RADSL, SDSL, UDSL or the like.

Additionally, the systems, methods and protocols of this invention canbe implemented on a special purpose computer, a programmedmicroprocessor or microcontroller and peripheral integrated circuitelement(s), an ASIC or other integrated circuit, a digital signalprocessor, a hard-wired electronic or logic circuit such as discreteelement circuit, a programmable logic device such as PLD, PLA, FPGA,PAL, a modem, a transmitter/receiver, any comparable means, or the like.In general, any device capable of implementing a state machine that isin turn capable of implementing the methodology illustrated herein canbe used to implement the various communication methods, protocols andtechniques according to this invention.

Furthermore, the disclosed methods may be readily implemented insoftware using object or object-oriented software developmentenvironments that provide portable source code that can be used on avariety of computer or workstation platforms. Alternatively, thedisclosed system may be implemented partially or fully in hardware usingstandard logic circuits or VLSI design. Whether software or hardware isused to implement the systems in accordance with this invention isdependent on the speed and/or efficiency requirements of the system, theparticular function, and the particular software or hardware systems ormicroprocessor or microcomputer systems being utilized. Thecommunication systems, methods and protocols illustrated herein howevercan be readily implemented in hardware and/or software using any knownor later developed systems or structures, devices and/or software bythose of ordinary skill in the applicable art from the functionaldescription provided herein and with a general basic knowledge of thecomputer and telecommunications arts.

Moreover, the disclosed methods may be readily implemented in softwarethat can be stored on a storage medium, executed on programmedgeneral-purpose computer with the cooperation of a controller andmemory, a special purpose computer, a microprocessor, or the like. Inthese instances, the systems and methods of this invention can beimplemented as program embedded on personal computer such as JAVA® orCGI script, as a resource residing on a server or computer workstation,as a routine embedded in a dedicated communication system or systemcomponent, or the like. The system can also be implemented by physicallyincorporating the system and/or method into a software and/or hardwaresystem, such as the hardware and software systems of a communicationstransceiver.

It is therefore apparent that there has been provided, in accordancewith the present invention, systems and methods for CRC normalization.While this invention has been described in conjunction with a number ofembodiments, it is evident that many alternatives, modifications andvariations would be or are apparent to those of ordinary skill in theapplicable arts. Accordingly, it is intended to embrace all suchalternatives, modifications, equivalents and variations that are withinthe spirit and scope of this invention.

1. A Cyclic Redundancy Checksum (CRC) anomaly counter normalizationmethod comprising: normalizing the CRC anomaly counter based on a valuefor a CRC computation period (PERp). 2-32. (canceled)